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1.0  Introduction 


Tne  concept  of  abstraction  has  become  an  important  part  of  problem 
solving  and  in  particular  software  development.  Through  the  use  of  abstract 
data  types,  programs  can  be  written  that  manipulate  objects  of  a  given  type 
without  being  concerned  with  how  the  primitive  operations  on  the  objects  are 
implemented. 

In  this  paper  we  describe  a  constructive  (or  operational) 
specification  method  for  specifying  abstract  data  types.  We  limit  our 
discussion  to  the  specification  of  data  abstractions  and  do  not  treat 
procedural  abstractions.  A  constructive  method  specifies  how  a  type's 
operations  affect  instances  of  the  type.  By  this  definition,  the  abstract 
model  ([BERZV79])  approach  can  be  considered  a  constructive  specification 
method  while  the  algebraic  method  ([GUTTJ75],  [G0GUJ78])  is 
nonconstructive. 

Tne  work  described  in  this  paper  includes  some  important  changes  in 
notation  to  the  constructive  specification  method  described  by  the  author  in 
[CL AY B 7 9 ]  and  [CLAYB80].  The  improvements  in  notation  permit  more  concise  and 
more  readable  specifications  to  be  written.  This  paper  gives  a  more  detailed 
description  of  the  method,  especially  with  respect  to  proofs  of  implementation 
correctness. 

Tnis  paper  is  organized  as  follows.  In  the  next  section  we  present  some 
preliminary  concepts  dealing  with  the  algebraic  and  abstract  model 
specification  methods.  In  Section  3  we  describe  the  constructive 
specification  method  by  specifying  stack,  mapping  and  symboltable  data  types. 
Then  in  Sections  4  and  5,  we  discuss  implementing  and  proving  implementation 
correctness  for  abstract  data  types  specified  constructively  using  the 
symboltable  data  type.  The  symboltable  data  type  example  was  chosen  because 
it  is  a  nontrivial  example  and  because  the  reader  can  readily  compare  the 
constructive  specification  given  for  it  in  this  paper  with  Guttag's  algebraic 


Problem  Studied 


The  proposed  research  was  to  develop  a  specification  method  for  the 
specification  of  abstract  data  types  and  an  access  control  facility  suitable 
for  inclusion  in  high-level  programming  languages.  The  research  was  not 
intended  to  include  the  design  of  a  complete  language  but  instead  involved  the 
development  of  programming  language  features  that  aid  in  the  development  of 
languages  designed  for  producing  reliable  software. 


Results  of  the  Research 

To  meet  the  objectives  of  this  research,  a  constructive  specification 
method  was  developed  for  specifying  abstract  data  types.  Abstract  data  types 
are  specified  using  the  module  encapsulation  mechanism.  A  constructive 
specification  consists  of  two  parts:  a  logical  structure  specification  and  a 
semantics  of  operations  specif ication.  T he  constructive  specification  method 
is  described  in  the  following  pages. 


specification  (in  [GUTTJ78]).  In  Section  6  we  treat  a  database  view  as  a 
data  abstraction  and  realize  it  as  an  abstract  data  type  and  specify  it  using 
the  constructive  specification  method.  This  particular  example  differs  from 
the  other  data  types  specified  in  this  paper  because  the  representation  data 
is  shared  by  all  instances  of  the  database  view.  In  addition,  it  illustrates 
at  least  one  important  difference  between  the  constructive  method  and  the 
algebraic  method.  Finally,  in  Section  7  we  present  a  rather  detailed 
comparison  of  specification  methods. 

2.0  Prel iminaries 

An  abstract  data  type  can  be  viewed  as  a  set  of  values  (or  objects) 
and  a  set  of  operations  applicable  to  the  values.  The  definition  of  an 
abstract  data  type  consists  of  a  specification  of  tne  type  and  an 
implementation  of  the  type.  A  specification  of  a  type  is  a 
representation-independent  description  of  all  properties  of  the  type.  This 
includes  specifying  the  syntax  and  semantics  of  a  set  of  primitive  operations 
applicable  to  the  type.  The  implementation  of  a  type  involves  assigning  a 
representation  for  the  set  of  objects  defined  and  tnen  implementing  the  type's 
primitive  operations  on  the  representation  selected.  A  stack  data  type,  for 
example,  is  often  represented  by  a  vector  and  the  stack  operations,  e.g.  push, 
pop,  etc.,  are  implemented  using  the  vector  and  its  operations.  In  turn,  the 
vector  type  itself  has  a  representation,  such  as  a  contiguous  block  of  memory 
cells,  and  a  set  of  operations  implemented  in  terms  of  this  representation. 

A  substantial  amount  of  work  has  been  done  to  develop  specification 
methods  and  languages.  These  approaches  to  specification  have  usually  been 
classified  as  algebraic  specifications  ([ZILLS75],  [GUTTJ78],  [ G0UGJ78] )  and 
aDStract  model  specifications  ([BERZV79],  [WULFW76],  [HOARA72 ] ) .  Each 
approach  has  its  advantages  and  disad 'antaqes  ([GUTTJ78],  [BERZV79]). 

Presently,  the  most  popular  method  for  specifying  abstract  data  types  is 


the  algebraic  specification  method.  The  reason  for  this  appears  to  be 


twofold:  (1)  the  algebraic  method  has  a  mathematical  basis  in  algebra  and 
has  been  formalized,  and  (2)  the  algebraic  method  has  been  widely  publicized. 

When  an  abstract  data  type  is  specified  algebraically,  it  is  viewed  as 
an  algebra.  One  then  writes  the  syntax  of  the  operations  and  the  axioms  of 
the  corresponding  algebra.  The  syntax  specification  defines  the  names, 
domains  and  ranges  of  the  type's  primitive  operations.  Writing  the  axioms  is 
considered  to  be  the  semantic  specification.  The  axioms  are  written  in  the 
form  of  equations  (or  rewrite  rules)  which  relate  the  primitive  operations 
of  the  type  to  each  other.  To  prove  implementation  correctness,  one  must  show 
that  an  implementation  satisfies  all  the  axioms. 

With  the  abstract  model  approach,  an  abstract  representation  (or 
abstract  object)  is  selected  for  objects  of  the  type  being  defined.  It  is 
important  that  the  users  of  a  type  know  what  its  abstract  representation  is 
since  the  semantics  of  the  type's  operations  are  specified  with  respect  to  the 
abstract  representation.  For  example,  the  abstract  representat ion  of  a  stack 
is  usually  a  mathematical  sequence.  The  syntax  of  a  type's  operations  is 
defined  just  as  it  is  in  the  algebraic  approach.  The  difference  between  these 
two  methods  involves  specification  of  the  semantics  of  operations.  The 
semantics  of  a  type's  operations  are  specified  by  specifying  how  each  of  the 
operations  affects  the  abstract  object  (some  operations  such  as  membership 
and  retrieval  operations  do  not  change  the  state  of  the  abstract  object.) 

This  essentially  means  that  to  specify  the  semantics  of  a  type's  operations  we 
specify  how  the  operations  affect  an  instance  of  the  type.  To  prove 
implementation  correctness,  the  implementation  of  each  individual  operation  is 
proven  correct  (with  respect  to  the  semantics  specified  for  it).  It  is 
noteworthy  to  point  out  here  that  an  abstract  object’s  operations  are  used 
only  in  specifying  the  semantics  of  a  type's  operations  and  are  not  used  in 
implementing  the  type. 

It  is  important  that  abstract  data  types  be  specified  using  a  formal 
specification  language  for  at  least  three  reasons: 


1}  communicating  the  properties  of  a  type  in  a  precise 
and  unambiguous  manner, 

2)  proving  implementation  correctness,  and 

3)  designing  abstractions. 

Communication  of  properties  in  a  clear  and  concise  manner  is  important  because 
this  permits  a  type  to  be  understood  by  both  the  user  of  the  type  and  the 
implementer  of  the  type.  Proving  implementation  correctness,  though  often 
nontrivial,  should  be  done  when  it  is  an  important  aspect  of  software 
development  for  an  organization  using  the  resulting  software.  For  instance, 
several  governmental  agencies  believe  that  trusted  software,  i.e.  verified 
software,  is  important  for  security  reasons.  Formal  specification  as  an  aid 
to  the  design  of  data  abstractions  may  be  the  most  important  reason  for  doing 
the  specification.  From  our  experience  in  realizing  data  abstractions  ranging 
from  simple  abstractions  such  as  stacks  to  more  complex  abstractions  such  as 
database  views,  formally  specifying  an  abstraction  usually  leads  to  a  "better" 
and  often  simpler  abstraction.  With  the  exception  of  a  few  cases  such  as  the 
one  just  mentioned,  ease  of  demonstrat ing  consistency  of  specif ications  and 
implementations  is  often  of  lesser  importance  than  ease  of  examinining  and 
manipulating  specifications. 

3.0  The  Constructive  Specification  Method 

As  stated  above,  a  complete  definition  of  an  abstract  data  type  consists 
of  a  specification  of  the  type  and  an  implementation  of  the  type. 

Specification  details  are  visible  to  a  programmer  while  implementation  details 
are  hidden  from  programmer  use.  We  will  use  the  module  encapsulation 
mechanism  described  in  [CIAV830]  to  define  abstract  data  types. 

The  constructive  specification  of  an  abstract  data  type  consists  of  two 
parts:  a  logical  structure  specification  and  an  operation  specification. 

Each  of  these  specifications  is  discussed  in  detail  below. 


3.1  The  logical  structure  specification 


When  a  programmer  specifies  an  abstract  data  type,  he  usually  has  some 
preconceived  notions  about  the  data  abstraction  such  as  what  an  instance 
"looks  like"  (independent  of  any  concrete  representation),  relationship(s) , 
if  any,  between  constituent  objects,  etc.  (an  instance  of  a  type  consists  of 
a  collection  of  constituent  objects).  In  the  constructive  approach,  these 
notions  are  communicated  to  the  user  and  implementer  of  a  type  via  a  logical 
structure  specification.  These  notions  tend  to  make  understanding  a  type  - 
easier  and  hence  aid  in  communicating  properties  of  a  type.  A  logical 
structure  specification  essentially  defines  an  abstract  model  of  the  type 
being  specified.  It  does  this  by  defining  relationship(s) ,  if  any,  between 
constituent  objects,  by  defining  restrictions  to  the  relationship(s),  and  by 
expressing  an  instance  of  the  type  as  a  tuple  of  elements.  The  elements  of 
such  a  tuple  may  be  sets  of  constituent  objects  and  relationship(s) . 

A  logical  structure  specification  does  not  specify  an  abstract  data 
type;  however,  it  is  an  important  part  of  the  specification  of  a  type  because 
the  semantics  of  operations  are  specified  in  terms  of  how  they  affect  an 
instance  of  the  type. 

The  unbounded  stack  data  type  in  Figure  1  illustrates  the  various  parts 
of  a  logical  structure  specification.  The  objects  section  contains  the  names 
of  the  types  of  constituent  objects.  Constituent  object  types  can  be  defined 
within  a  logical  structure  specification  (see  Figures  2  and  3)  or  they  can 
be  passed  as  parameter(s)  to  a  defining  module  (see  Figure  i).  The 
relationships  section  defines  any  relationship(s)  that  may  exist  between 
constituent  objects. 


k 


module  mapping[doinaintype:  Type,  rangetype:  Type]; 

Togical  structure 
objects 

type  N0D£  =  record  NAME:  domaintype; 

ATTRIB:  rangetype 

end; 

occurrence  <M:  collection  N0DE> 
operations 
syntax 

NEWMAP:  — ^  mapping 

defmap:  mapping  x  domaintype  x  rangetype  — >  mappin 
evmap:  mapping  x  domaintype  — ^  rangetype u (UNDE FI N 
isdefined:  mapping  x  domaintype  — >  boolean 
s  ema  n  t i c  s 

ID:  domaintype;  ATTRLIST:  rangetype;  m:  mapping; 
NEWMAP  =  0; 

evmap(m,ID)  =  vf  -Jx  4  m}-  x.NAME  =  ID 
then  x. ATTRIB  else  UNDEFINED; 


isdefined(m,  ID)  =  if  J  x  ^  m  i  x.NAME  =  ID 
then  TRUE  else  FALSE; 

defmap(m,  ID,  ATTRLIST)  =  m  u  f  x  with  [NAME  =  ID, 
ATTRIB  =  ATTRLIST]]  ; 

end  mapping; 


Figure  2.  Constructive  specification  of  mapping  aata  type 


rn  cO 


module  stack[elementtype:  Type]; 

logical  structure 

object  ELEM:  elementtype 
relat  ionships  ONTGPOF:  ElEM  to  ELEM 
occurrence  <S:  col  lection  ELEM,  0:  ONTOPOF^ 
invariant  assertions 

1 .  0NTOPQF  is  1  inear 


operations 

syntax 

NEWSTACK:  - =>  stack 

pusn:  stack  x  elementtype  >  stack 

pop:  stack  - >  stack 

top:  stacK  — >  elementtype  u  {UNDEFINED] 
replace:  stack  x  elementtype  — >  stack  u  {eRRORj 


semantics 

x,  y,  z:  elementtype;  s:  stack; 

NEWSTACK  =  <#,  p  > 

push(s,  x)  =  s  with  [S  =  S  u  N  ,  0  =  if  , 
s  =  NEWSTACK  then  f/t  el  se  0  ufex,  top(s)>j] 

pop(s)  =  S  =  ^  then  NEWSTACK 

else  s  with  [S  =  S  -  f*}  ,  0  =  0  -  fcx,  y>l 
^x,  y><0  ]  where  x  =  top(s) 


top(s)  =  vf  s  *  NEWSTACK  then  UNDEFINED  else  x 
where  x  <  S  and  {  p  y  <  S)  (  ^y,  x>  4  0) 

replace(s,  x)  =  if  s  =  NEWSTACK  then  ERROR 
else  s  withes  *  (S  -  W'Tuix]  , 

0  =  To  -  <y,z >  )  u[<fx,  z>]  ] 
where  y  =  top( s ) 

end  stack; 


Figure  1.  Constructive  specification  of  unbounded  stack  type 


module  symbol  tab le[domaintype:  Type,  range  Lyp<-:  Type]; 

logical  structure 
objects 

Type  Nfinr  _  (t,COrc  NAME:  oomaintype; 

'  ATTRIB:  rangetype 

end; 

type  BLOCK  =  record  CONTENTS:  col  lection  NODE;  enc; 
re  1  at  ionsn  i p s  NESTED:  BLOCK  t_o  BLOCK 
occurrence  <  N:  c o 1 1 ec t i on  NODE, 

B:  collection  BLOCK,  ND:  NESTED^ 
invariant  assertions 

H  NESTED  is  1  inear 

2.  b  ■*  Co,  o '  >  <  NO  «  o'  4  B 


operations 

syntax 

I  NIT:  • — >  symDol table 

*currentblock :  symboltable  - ^  BLOCK 

enterblock:  symboltable  — *  symboltable 
leaveoiock:  symboltable  — *  symboltable 

isinolock;  symboltaDle  x  oomaintype  - >  boolean 

retrieve:  symboltable  x  domaintype  - i  rangetype 

aodid:  symboltable  x  oomaintype  x  rangetype  - — > 

symbol  tab  1  e 


semantics 

b,  bi,  cb:  BLOCK;  x:  NODE;  ID:  noma  intype; 
ATTRLIST:  rangetype;  s:  symboltaole; 

INIT  =  s  with  [N  =  /,  B  =  fb  witn  [b. CONTENTS  = 

nd  =  ft 

currentblock(s)  =  b  where  ^Di  4  B  -ft-  kToi,  b>  4  ND: 

enterblock(s)  =  S  with  [Bufb  with  [CONTENTS  =  f)  ]f, 

ND  =  NDu[<b,  cb>J  ,  wnere  b  B; 

leaveblock(s)  =■  vf  ND  =  f>  then  INIT 

el se  S  with  [N  -  N  ~  [cb. CONTENTS]  , 
B  =  8  -  [cb]  ,  , 

ND  =  NO  -  [<Co,  b>  ( Ccb,  b>*N0jj 

isinblock(s,  ID)  =  if  j  x  4-  cb.CON'E NTS  >x.NAMl  =  ID 
tnen  TRUE  else  FALSE ; 


retr i eve( s , I D)  =  if  s  =  INIT  then  UNDEFINED 

else  if  3  x  •*  cb. CONTENTS  *x. NAME  =  ID 
TFTen  x. ATTRIB 

else  retr i eve( 1 eaveb 1 ock ( s ) ,  ID); 

addid(s,  ID,  ATTRLIST)  =  s  with  [N  =  N  u  {  x  with 
[NAME  =  ID,  ATTRIF^ATTRLIST]L 
B  =  B  wi_th  [cb. CONTENTS  =  cb. CONTENTS  "Wit 

end  symboltable; 


Figure  3.  Constructive  specification  of  symboltable  data  type 


Possibly  the  most  important  ingredient  of  a  logical  structure 
specification  is  the  invariant  assertion.  The  primary  functions  of  the 
invariant  assertion  are  to  specify  restrictions  to  relationships  and  to 
specify  assertions  about  the  model  on  which  the  semantics  of  operations  are 
specified.  When  the  semantics  of  operations  are  specified,  care  must  be  taken 
to  ensure  that  the  operations  do  not  "violate"  or  "ignore"  any  of  the 
assertions. 

Tne  austract  data  types  specified  in  this  paper  do  not  reflect  the  true 
importance  of  the  invariant  assertions.  Invariant  assertions  are  particularly 
valuable  in  specifying  abstract  data  types  wnere  there  are  several 
relationships  between  constituent  objects  and  there  are  important  restrictions 
to  these  relationships,  for  example,  in  specifying  database  views  there  are 
usually  several  relationships  between  entity  types.  As  an  example,  a 
specification  of  the  presidential  database  descriDed  in  [TAYIR76]  required  26 
invariant  assertions.  In  this  context,  a  logical  structure  specification  is 
analoguous  to  a  database  subscnema  definition.  However,  there  is  an  important 
difference  betweeen  a  logical  structure  specification  and  say  a  CODASYL 
subschema  definition.  The  invariant  assertions  of  a  logical  structure 
specification  define  the  semantics  of  the  relationships  between  entity  types. 

A  CODASYl  suoschema  definition  can  only  define  the  syntax  of  the  relationships 
and  not  the  semantics. 

Wyckoff  ( [WYCKM80] )  has  suggested  the  use  of  diagrams  to  pictorially 
describe  data  types  specified  using  the  constructive  approach.  These  diagrams 
can  be  used  to  aid  in  the  specification  of  a  data  type  or  by  a  user  and  an 
implementer  to  help  them  understand  the  type.  A  diagram  can  be  drawn  directly 
from  a  logical  structure  specification.  Diagrams  for  the  stack,  mapping  and 
symboltable  data  types  are  shown  in  Figure  4.  As  we  will  see,  the  diagrams  in 
Figure  4  aid  us  in  developing  and  understanding  the  correspondence  function 


given  in  Figure  6.  In  these  diagrams  a  R  b,  i.e.  object  a  is  related  to 
object  b  via  relation  R,  is  represented  as 


To  take  a  closer  look  at  logical  structure  specifications,  we  examine 
the  unbounded  stack  data  type  and  the  symboltable  data  type  in  Figures  1  and 
3,  respectively.  The  stack  type  is  a  parameterized  type  with  the  type  of 
elements  in  a  stack  instance  passed  as  a  parameter.  An  instance  of  the  stack 
type  consists  of  a  collection  of  objects  of  type  elementtype.  The 
relationship  between  the  elements  of  the  stack  is  0NT0P0F;  0NT0P0F  is  linear 
([CLAYB79]  provides  a  list  of  terms,  such  as  linear,  is  ordered  on,  etc.,  that 
expedite  writing  invariant  assertions.)  The  terms  used  in  this  paper  should 
be  self  explanatory. 


N1 :  NODE,  e^:  elementtype; 

0NT0P0F  =  [^N3,  N2>  ,  CN2,  Nj>J 

4(a)  diagram  of  stack  data  type 
d2  r2 

m3  m2 

Mi :  NODE;  d, :  domaintype;  r-,:  rangetype; 

4(b)  diagram  of  mapping  data  type 


NESTED  =  [^b3,  b2>  ,  ^b2,  bi>] 


4(c)  diagram  of  symboltable  data  type 
Figure  4.  Diagrams  of  stack,  mapping  and  symboltable  data  types 

Constituent  objects  of  a  symbol  table  consist  of  instances  of  BLOCK  and 
NODE.  These  object  types  are  defined  within  module  symboltable;  however,  the 
types  of  the  component  elements  of  NODE  are  passed  as  parameters.  The 
relationships  and  occurrence  sections  need  no  explanation;  however,  the 
invariant  assertions  section  does  require  some  explanation.  Assertion  2  states 
that  there  is  a  block  which  is  assumed  to  be  global  to  all  blocks  in  a 
program.  This  same  assumption  is  made  in  Guttag's  specification  of  the 
symboltable  data  type  ( [ GUTTJ78] )  but  it  is  not  explicitly  stated. 


3.2  Specification  of  operations 

The  operat i ons  section  consists  of  two  parts:  a  syntax  specification  ,mc 
a  semantics  specification.  The  syntax  section  defines  the  names,  domains  ana 
ranges  of  a  type's  primitive  operations.  Hidden  (or  auxiliary)  operations, 
i.e.  operations  that  are  used  in  specifying  other  operations  out  are  not 
available  for  programmer  use,  are  indicated  by  placing  an  asterisk  ('*')  to 
the  left  of  their  name.  Operation  cur rent block  in  Figure  3  is  an  example  of  a 
hidden  operation. 

In  many  cases,  specifying  the  semantics  of  a  set  ol  operations  using  trie 
constructive  approach  is  straightforward.  With  respect  to  the  symboltable  data 
type  in  Figure  3,  tne  1NIT  operation  creates  a  symbol  ta.'le  ana  establishes  the 
outermost  scope.  Operation  enterblock  establishes  a  new  block  nested  in  the 
current  ulock  ana  Oeavcb  I  qck  removes  the  current  interrrvst  block.  Operation 
is  inblock  tests  whether  or  not  an  identifier  has  been  declared  in  the  current 
block  ana  retrieve  retrieves  the  attribute  list  of  an  identifier  from  the  bloc* 
closest  to  the  innermost  Dlock.  Operation  add  id.  is  explained  by  the  following 
example.  The  symool  table  for  the  program  shown  in  Fig-re  o  at  the  point  of 
compilation  indicated  by  the  arrow  is  given  by 

addid(addid(enterblock(adoid( init,  x,  real)),  x.  complex;,  y,  complex). 

begin 

x:  real; 


begin 

x,  y;  complex; 

end 

end 


Figure  5.  Program  segment 


4.0  Implementation  of  Abstract  Data  Types 


An  implementation  ot  an  abstract  data  type  using  the  constructive 
specification  metnoo  consists  of  a  representat 1  on  specif  ication  followed  by 
an  implementation  of  tne  type's  operations  witn  respect  to  tne 
representat i on .  Tne  representat ion  specification  ot  an  abstract  data  type 
indicates  tne  concrete  object  s;  used  to  represent  tne  t yp^  ano  tne 
correspondence  between  an  abstract  object  and  its  concrete  object(s). 
Corresponuen>_e  is  aet  ined  as  a  function  trom  concrete  obj-  t  to  an  abstract, 
object.  The  correspondence  function  is  a  nomorphism  and  :t  is  identical  in 
functionality  to  tne  abstraction  function  ot  Hoare  (lm-JA j/.  A 
correspondence  function  is  named  and  it  is  used  in  prooft.  ot  implementation 
correctness . 

A  correspondence  function  may  be  relatively  simple  a  it  is  tor  tne 
symooltable  data  type  and  its  representation/  or  it  may  oe  Quite  cample*.  In 
general,  tne  more  dissimilar  the  concrete  objects  a>  3  tn-  ib  t -  a  t  vau-"  tne, 
represent,  the  more  complex  the  correspondence  function. 

Tne  correspondence  function  tor  tn,-  nig, ,  ems-nt  at  ion  ’  tn,-  symboitable 
data  type  in  Figure  6  is  STMT.  The  concrete-  objects  in  tms  case  are 
instances  ot  tne  stack,  and  mapping  data  types  specified  in  Figures  <•'  and  J, 
respectively.  SYMT  maps  these  concrete  objects  into  3  symbol  table.  The 
occurrence  tuple  snown  in  Figure  n  represents  an  occurrence  of  symooltable 
where  N  =  UH,  B  *  S  and  ND  =  0.  M  is  defined  in  Figure  X  and  b  and  0  are 
defined  in  Figure  1.  This  definition  of  SYNf  can  be  easily  un,,erstood  by 
looking  at  Figure  4.  Implicit  in  the  definition  of  bYMT  is  tne  fact  that  a 
bloc*  is  equivalent  to  an  element  of  a  stack  ana  each  element  of  a  star*  is  a 
collection  of  mappings. 

The  imp lementat ion  section  provides  an  implementation  ot  an  abstract 
data  type's  operations  in  terms  of  concrete  object(s)  and  concrete  object 


r 


operations.  An  implementation  of  an  operation  is  specified  using  composition 
of  operations,  tests  for  equality  (or  inequality)  and  tne  lf-then-else 
construct.  An  implementation  of  tne  symbol  tab  I e  data  type  is  given  in  Figure 
6. 


represent  it i on 


SymtaD:  symbo  1  taD  1  e ;  stk:  stack;  m:  oiapp  l  ng ; 
symtau  =  SYMT(stk(m))  where  SYMT(stkvm))  =  ^uM,  S,  0> 


imp  1 ementat l on 

st*:  s tdL * ;  id:  domaintype;  attr:  rangetype; 

I N I T  =  SY  M7 ( pusn ; NE WSTACK ,  NEWMAP)) 

enteroluv.*.;  SYV.:  ;st*  j  )  ^  S’’  M '  ( pusn  (  stk  ,  NEWMAP  i) 

addid( SYMT ( Stk  ) ,  id,  attr)  = 

SYMT (rep lacev su ,  uefmap' top  stk,,  id,  attr))) 

leaveb )0Ck( SYMT ( Stk  ;  )  =  it  o  =  &  then 

^TMT  (pusnlNTu:.’  Av.k,  NEWMAP)) 
else  SYMT ( pop(  sU  ) ) 

retr  levei  SYMT  i  stk  ) ,  10)  =  j_f  stk  =  pusfnNEWSTACk,  NEWMAP) 

then  JNl£  K I NE  0 
else 

Tf*  isdef  ined(top(stk  ) ,  id) 
then  evmap( top f stk ) ,  id) 
else  retr ieve( leaveblock( 
SYMT ( stk )) ,  id) 

is  mo  lock  (  SYMT  ( stk ) ,  J(3/  _  isdef  ined(  top(  stk ) ,  id) 
currento  lock  v  SYMT  (stk  ,- )  =  t  op  (stk) 


Figure  6.  A  representat i on  and  an  implementation  of  syrnholtable  data  type 


5.0  Proving  Imp  ementat i on  Eorrec tness 

For  the  constructive  specification  method,  a  proof  of  implementation 


correctness  invulves  snowing  that  the  implementation  of  earn  individual 
operation  is  correct  with  respect  to  a  correspondence  function.  That  is,  for 
the  symooltabie  data  type  we  must  snow  the  following: 


for  each  symboltable  operation  t7”  show  that 


^T(SYMT)  =  SYMT  (  1  ) ,  where  tj~  '  is  an 

implementation  of  q-  . 

A  pictorial  view  of  SYMT  is  given  in  Figure  7  using  the  implementation  of 
symboltable  operation  addid.  This  pictorial  description  suggests  that  proving 
implementation  correctness  involves  showing  that  the  instance  resulting  from 
the  left  side  of  each  operation  implementation  (given  in  Figure  6)  is  the 
same  as  the  instance  resulting  from  tne  corresponoing  right  sioe. 


replace(stk ,...)• 


SYMT 


addid(symtab, . . . ) 


->  SU  ' 


SYMT 


* 

->  symtaD ’ 


Figure  7.  Pictorial  meaning  of  addid(SYMT)  =  SYMT(replace) 


Before  a  proof  of  implementation  correctness  can  be  done  for  the 
symDoltable  data  type,  it  is  necessary  to  prove  an  implementation  invariant. 

In  general,  an  implementation  invariant  is  a  property  that  is  true  for  all 
values  of  a  type  produced  oy  an  implementation  of  the  type.  An  implementation 
invariant  comes  up  as  one  proceeds  through  a  proof  of  correctness.  They  make 
tnemselves  obvious  when  the  rewrite  process  during  a  proof  can  no  longer 
continue.  In  general,  one  may  not  know  all  the  implementation  invariants  when 
a  proof  is  initiated. 

For  the  symooltable,  the  following  implementation  invariant,  posed  as  a 
theorem,  must  be  proven: 

for  each  symDoltable  =  SYMT(stk),  stk  J  NEwSTACK. 

To  prove  the  theorem,  we  must  show  that  the  invariant  is  true  for  all 
symooltable  operations  that  produce  symDoltable  values.  Since  IN1T, 
enterplock,  addid,  and  leaveblock  are  the  symboltable  operations  that  produce 

i 


Proof 


right  side 

SYMT(push(stk, 


NEWMAP) ) 


=  SYMT  (stk  with  [S  =  S  \j  (hz  wMApJ  ,  0  =  if  stK  =  NEWSTA..K 

then  /  else  0  v  /<CNE  WMAP ,  topfstkJ^J] 

(by  semant  ics  or  pu  shf ) 

=  SYMF (stk  with  [S  =  So  {NEWMAP}  ,  0  --  Ou(<NEWMaP, 

top(stkj>  J  ] 

(by  implementation  invariant) 


=  symtab  with  FB  = 
ND  =  NDuf^b, 
(by  correspondence 


Bo{u  with  [COMENTb  -  ('< 
cb  >  J  J 

function  SYMT  in  F  ig.,rc  •■> 


left  side 

enterolock(SYMT(sU/ )  =  entero lock ( symtab/ 

(by  definition  of  SYMT) 

=  symtab  with  [B  0  {d  w i t n  [CONTENTS  =  i  j, 

ND  =  NDufcb,  cb>'J  ]  where  b  f  B 
(by  semantics  of  enterblock ) 

The  left  and  right  sides  are  equal  since  NEWMA3  ^  . 

Figure  9.  Proof  of  implementation  correctness  for  operation  ent erb_l or  >- 

5 . 1  Comments  on  proofs  of  implementation  correctness 

Proofs  of  implementation  correctness  for  types  specifieo  using  the 
constructive  approach  are  relatively  straightforward.  For  the  constructive 
specification  of  the  symboltable  data  type  the  degree  of  difficulty  for  a 
proof  of  implementation  correctness  is  about  the  same  as  for  Guttag's 
algebraic  specification  (see  [GUTTJ78]).  The  proof  of  implementation 
correctness  for  the  sympoltable  implementation  given  in  Figure  6  is  relatively 
simple  since  the  representation  ano  instances  of  the  type  are  very  similar  in 
nature.  When  the  representat ion  of  a  type  and  instances  of  the  type  are 
dissimilar,  in  general,  the  proofs  become  more  difficult.  For  example,  we 
specified  an  ordered  linear  list  (using  both  the  algebraic  specif’  ition 


symooltdule  vju»-s,  it  suffices  to  snow  mat  given  a  stacs,  sts,  for  which  the 
invariant  is  true,  each  of  these  operations  produces  a  new  stacK  for  which  the 
invariant  is  still  true.  Thus,  we  will  have  shown  inductively  that  the 
invar  Ijrt  is  true  t  ur  a’i  values  of  the  symboltable  type.  InyCkoff 

,  ■  gives  a  o  ^  ete  pr  oof  uf  the  invariant;  we  repeat  only  the  proof 
ihvui»’-r  ,  .ip  era  lion  ado  id  (see  Figure  8). 

a  ...  :  .»*>•  ,i,  ,  to.  jttr,  =  Sfwt(replace(stk,  def  mapi  top ;  sts ) ,  id,  attr))) 

(by  implementation  of  operation  add i d ) 

u.'iet*  sts  y  NlwSTACK  Dy  hypothesis  and  letting 
a  =  def map( top{ stk ) ,  id,  attr) 

=  yy  w_i_m  a  ^  i  S  )  U  [a]  ,  o  =  t  u  -  <f  y,  z>)  0 

Wd,  }  .  Where  y  ^  top(stk)) 

1  itiv  semantics  of  rep  lace) 

-  ->Y  *■' r  (  S  t  K  ‘  /  where  Sts'  f  NElnSTACK 

Therefore  the  invariant  is  true  lor  operation  .add id. 

Figure  8.  Proof  of  the  implementation  invariant  using  operation  addid. 

A  complete  prout  of  implementation  correctness  for  the  implementation 
given  in  Figure  b  IS  given  Dy  WyCsoff.  To  illustrate  Our  proof  procedure,  we 
repeat  only  a  proof  of  implementation  correctness  tor  operation  interblock 
(see  Figure  y).  The  other  proofs  are  similar.  In  Figure  9  we  show 
entero  1  ocs  (  SVKT  (  Sts  j  )  =  STMT  (  puSh(  stk  ,  NrnMAP  j  ) 
by  snowing  that  the  instances  resulting  from  the  left  and  right  sides  are 
ldentica I . 

Tne  development  of  the  right  side  in  Figure  y  makes  use  of  the  semantics 
of  stack  operation  gush ,  the  implementation  invariant  defined  above,  the 
function  SVMT,  and  the  fact  that  cb  =  top(sts).  Tne  development  of  the  left 
side  is  simpler  ana  makes  use  of  the  semantics  of  operation  enterblock  and 
STMT. 


method  and  the  constructive  method)  and  then  implemented  it  using  a  binary 
searcn  tree.  In  our  attempts  to  complete  a  proof  of  implementation 
correctness  for  the  list,  we  had  to  consider  several  special  cases  of  the 
binary  searcn  tree  for  botn  specifications.  For  the  algebraic  specification, 
considerable  ingenuity  was  required  as  well  as  proving  some  auxiliary  theorems 
to  permit  rewriting  to  continue  during  proofs  (see  [CLAfBSlbjj.  Like  the 
proofs  for  the  algebraic  specification  of  the  linear  list,  the  proofs  for  the 
constructive  specification  were  relatively  long;  however,  tney  were 
straightforward  in  comparison. 

6.0  A  Database  View  Example 

In  this  section  we  realize  a  database  view  an  an  abstract  data  type  and 
specify  it  using  the  constructive  specification  method.  This  example  is 
included  because  database  views  are  substantially  different  than  the  other 
data  abstractions  specified  in  this  paper.  The  difference  exists  because 
databases  are  normally  shared  data  objects  with  many  different  users  capable 
of  updating  the  database  and  the  updates  may  affect  the  values  of  a  view. 

A  database  view  is  an  abstraction  of  an  underlying  database.  A  view  has 
the  following  properties: 

1)  an  underlying  database  is  assumed  to  exist;  otherwise,  it  is 
impossible  to  derive  a  view, 

2)  views  are  not  materialized,  i.e.  they  are  not  stored  in  a 
database,  and 

3)  in  a  shared  database  environment,  some  values  of  a  view  may 
be  created  by  other  users  who  are  updating  the  underlying 
database. 

An  underlying  database  is  considered  to  be  the  representation  of  a  database 
view  and  an  implementation  of  a  database  view  is  an  implementation  of  the 
view's  operations  with  respect  to  the  underlying  database. 


In  the  example  described  below,  the  database  view  specified  is  a 
relational  view  {[UATEC77]).  For  simplicity,  we  assume  that  the  view 
consists  of  a  single  relation  (referred  to  as  a  view  relation)  and  the 


representation  is  a  single  relation  (referred  to  as  a  base  relation)  stored 
in  the  database.  The  base  relation  consists  of  a  set  of  tuples  with  the 
following  attributes 

(car_no,  model,  booy_no,  yr,  current_val ue,  mi,  disp,  dest,  rc,  col,  loc) 
while  an  instance  of  the  view  relation  consists  of  a  set  of  tuples  with  the 
following  attributes 

(car_no,  mi,  dest,  disp,  rc) 

Each  car  owned  by  the  car  rental  company  (described  below)  has  a  tuple 
corresponding  to  it  stored  in  the  database  with  car_no  being  a  primary  key. 

The  environment  for  this  example  is  as  follows.  A  car  rental  company  in 
a  large  city  has  a  central  headquarters  where  car  purchases  are  made, 
allocations  of  cars  to  local  rental  offices  are  made,  etc.  When  a  new  car  is 
purchased,  all  information  on  the  car  such  as  license  plate  number  (car_no), 
body  identification  number,  color,  model,  etc.  are  stored  in  the  database  by 
headquarters  database  system  personnel.  When  a  car  is  assigned  to  a  local 
rental  office,  the  value  of  the  location  attribute  of  the  particular  car's 
tuple  is  set  to  the  location  of  the  local  office  to  which  it  is  assigned  and 
its  disposition  (disp)  is  set  to  'avail',  meaning  that  it  is  available  to  be 
rented. 

The  function  of  a  local  rental  office  differs  from  that  of  the 


headquarters.  A  rental  office  does  not  need  access  to  all  of  the  information 
in  a  car  tuple.  For  this  reason,  a  local  office's  database  consists  of  a  set 
of  the  view  relation  tuples  described  above.  A  local  office  can  apply  the 


operations  rent_car,  return_car,  maint_car,  return_maint ,  and  avail_car  to  its 

l_l  _ -  Wi_i  I _  -  — 

database  represented  by  its  view.  Operations  rent_car  and  return_car  a*-e  used 

-if  ii — im  m  Mii—  _n  f — 

when  a  car  is  rented  and  returned,  respectively.  Operations  maint  car  and 


return  maint  are  used  when  a  car  is  sent  to  maintenance  and  returned  from 


maintenance,  respecti vely.  Operation  avail_car  is  used  to  obtain  a  set  of 
available  cars  having  a  specified  rate  class.  The  rental  car  database  view 
described  here  is  a  simplified  version  of  a  view  described  in  [CLAYB81a].  In 
the  description  of  the  view  in  [CLAYB8Ia],  the  view  also  has  rental  car 
history  and  maintenance  history  view  relations. 

The  database  view  is  realized  as  the  abstract  data  type  dbview  and 
specified  using  the  constructive  specification  method  (see  Figure  10).  In 
this  specification  we  assume  that  the  data  types  car_number,  mileage,  etc.  are 
available  for  use  in  module  dbview.  Type  re_set  is  defined  as  a  set  of  car 
numbers.  Type  dbview  is  a  parameterized  type,  with  parameter  xloc  (the  value 
of  xloc  is  a  local  rental  office  location).  A  particular  instance  of  dbview 
is  a  set  of  tuples  consisting  of  only  those  cars  assigned  to  a  particular 
local  rental  office.  For  this  reason  the  local  office  location  does  not  have 
to  be  specified  as  a  parameter  in  each  of  dbview’s  operations. 


module  dbview(xloc:  location); 

Togical  structure 
objects 

type  TUPLE  =  record  ca:  car_number; 

mi:  mileage; 
dest:  destination; 
disp:  disposition; 
rc:  rate_class 

end; 

occurrence  < col  1 ect i on  TUPLE  > 

operations 

syntax 

rent_car:  dbview  x  car  number  x  destination — *»dbview  U 

(undefined} 

return_car:  dbview  x  car_number  x  mileage  — ■>  dbview  u 

(ERROR] 

maint_car:  dDview  x  car_number — ^dbviewu  (ERROR] 
return_maint:  dbview  x  car_number  — **  dbview  u[ERR0R] 
avail_car:  dbview  x  rate_class  - ^  rc_set 

semantics 

c:  car_numoer;  d:  destination;  m:  mileage; 
r:  rate  class;  t:  TUPLE;  db:  dbview; 
rent  car^db,  c,  d)  = 

If  }t  4  db  •*■  ( t.co  =  c  and  t .disp  =  'avail') 
then  db  with  [t.disp  =  'rented,  t.dest  =  d] 
eTse  UNDFFTnED; 

return_car(db,  c,  m)  = 

if  3-t  ■€  db  (t.ca  =  c  ana  t.disp  =  'rented'  ) 
then  db  with  [t.disp  =  'avail',  t.mi  =  m] 
el se  ERROR; 

maint  car(db,  c)  = 

iT  9-t«ob  ^tt.ca  =  c  and  t.disp  =  'avail') 
then  db  with  [t.disp  =  'maint' j  else  ERROR; 

return_maint(ab,  c)  = 

i f  ■Jt<db  ■i-  (t.ca  =  c  ano  t.disp  =  'maint'j 
then  db  with  [t.disp  =  'avail']  else  ERROR; 

aval  l_car(do,  r)  =  (t.ca  |  t<ub  and  t.rc  =  r  and 
t.disp  =  'avail '  J  ; 

end  dbview; 


Figure  10.  Constructive  specification  of  a  relational  database  view 


A  representation  of  dbview  is  given  in  Figure  11.  In  this 
representation  specification,  the  correspondence  function  VIEWMAP  is  defined 
as  a  derivation  of  view  relation  tuples  from  base  relation  tuples.  This  is  a 
natural  way  to  define  correspondence  functions  for  relational  database  views 
and  has  been  adopted  in  RIGEL  ([ROWEL79])  and  in  EXT_Pascal  ( [CLAYB81 a] ) . 


representation 

do:  dbview; 

db  =  VIEWMAP(R)  where 

VIEWMAP(R)  =  [<r.ca,  r.mi,  r.aest,  r.disp,  r.rc>| 
r^R  and  r.loc  =  xlocj 

Figure  11.  A  representation  for  view  dbview 

The  function  VIEWMAP  defines  an  instance  of  dbview  as  consisting  of  a  set  of 
tuples  having  the  five  attributes:  Ca,  mi,  dest,  disp,  and  rc.  R  is  the 
representation  of  instances  of  dbview  and  it  is  the  base  relation  from  which 
instances  of  dbview  are  derived. 

An  implementation  of  ubview's  operations  is  omitted  here  but  they  would 
be  implemented  in  terms  of  R's  operations,  namely  appenc,  delete  and  replace. 
The  interested  reader  should  see  [CLAVB81bJ  for  an  implementation  of  dbview 
and  a  proof  of  implementation  correctness  for  some  of  dbview' s  operations. 

6.1  Comments  on  tne  database  view  example 

The  database  view  example  was  included  in  this  paper  for  two  reasons; 

(1)  to  show  the  utility  of  the  constructive  specification  method,  ana  (2) 
to  serve  as  an  example  for  comparison  with  the  algebraic  specification  method 
in  an  environment  where  sharing  of  representation  data  occurs. 

In  the  database  view  example,  values  of  an  instance  of  dbview  may  be 
created  by  the  headquarters  database  personnel.  For  example,  a  car  tuple  may 
be  removed  from  a  view  if  the  location  of  the  car  is  modified,  i.e.  the  car  is 
assigned  elsewhere  or  sold,  by  headquarters  personnel,  or  the  headquarters  may 
decide  to  alter  the  rate_class  of  some  or  all  of  its  cars. 

Specifying  uata  abstractions  in  whicn  representation  data  is  shared 
causes  no  particular  problems  for  the  constructive  specification;  however,  it 
does  cause  some  prodlems  for  the  algebraic  method.  The  reason  for  this  is 
that  with  the  algebraic  method,  the  behavior  of  an  object  and  the  generation 
of  that  object  are  intertwined.  The  problem  incurred  by  the  algebraic  method 
is  that  some  of  the  constructor  operations  that  create  values  of  dbview  are 


not  in  dbview's  operation  set  but  instead  are  included  in  the  underlying 
database's  operation  set.  With  the  algebraic  specification,  all  values  of  an 
abstract  data  type  must  be  produced  by  some  sequence  of  constructors.  To 
specify  dbview  algebraically,  we  have  to  include  the  au-iliary  (or  hidden) 
operations  emptyv^ew  ana  aud_car.  Clayoroo^  ( [CLAY iidlb j J  provides  a 
complete  specification  of  doview  using  Guttag's  algebraic  specification 
method.  The  specif icotion  requires  12  axioms. 

7 .0  Comparison  of  Specification  Methods 

Below  we  summarize  properties  and  characteri sties  of  constructive  and 
algebraic  specification  methods.  Each  method  appears  to  have  some  inherent 
problems  that  are  difficult  to  nandle.  It  may  seem  that  we  are  overly 
criticizing  the  algebraic  specification  method.  However,  one  of  the  problems 
in  comparing  these  two  methods  is  that  the  algebraic  method  has  been  examined 
and  researched  by  more  people  than  the  constructive  method  and  thus  more  is 
known  about  its  strengths  and  weaknesses. 

In  the  algebraic  approach,  a  data  type  is  specified  by  giving  a  set  of 
axioms  relating  tne  type's  primitive  operations.  For  the  constructive 
specification,  the  logical  structure  of  a  type  is  specified,  thus  defining  an 
abstract  model  of  tne  type,  and  the  operations  are  specified  with  re. pec t  to 
this  model.  With  the  abstract  model  approach,  an  abstract  object  such  as  a 
sequence  or  set  is  selected  and  the  type’s  primitive  operations  are  specified 
with  respect  to  the  abstract  object.  The  constructive  specification  method 
described  in  this  paper  is  very  similar  to  the  abstract  model  approach; 
therefore,  any  comments  made  about  one  applies  to  the  other. 

Algebraic  specifications  are  usually  considered  to  be  more  elegant  than 
specifications  developed  using  a  constructive  method.  If  we  do  not  consider 
hidden  operations  as  unnecessary  detail  then  the  algebraic  method  does  not 
introduce  unnecessary  detail.  Since  it  has  a  mathematical  basis  in  algebra, 
it  is  well  suited  to  formal  analysis  and  has  been  used  as  the  basis  for 


"semi-automatic"  verification  systems  such  as  AFFIRM  ([MUSSD79]).  Another 
feature  of  tne  algebraic  specif ication  method  is  that  it  is  compact;  however, 
as  we  shall  see  below,  algebraic  specifications  are  not  always  compact. 

Several  authors  ([FLONL79],  [BERZV79],  [MAJSM79])  have  pointed  out 
some  serious  problems  witn  algebraic  specifications.  These  problems  are  for 
the  most  part  inherent  in  the  basic  methodology  used  to  develop  the  method 
and,  thus,  are  difficult  to  remedy.  Fortunately,  most  of  these  problems  are 
not  problems  for  the  constructive  metnods.  Majster  ([MAJSM79])  states  that 
one  of  the  problems  with  algebraic  specifications  is  the  necessity  to 
introduce  hidden  or  auxiliary  operations  for  some  specifications.  These 
operations  are  not  harmful  from  a  theoretical  point  of  view  but  they  do  cause 
two  problems.  The  number  of  auxiliary  operations  can  become  quite  large  and 
the  number  of  axioms  may  increase  sharply  (especially  if  some  of  the 
auxiliary  operations  must  be  constructors).  Majster  performed  a  case  study 
for  the  description  of  a  file  with  nine  (9)  operations  and  10  auxiliary 
operations  and  ended  up  with  over  50  axioms.  One  of  the  claimed  benefits  of 
algebraic  specifications,  compactness,  was  lost  in  this  specification. 

Another  problem  is  that  tne  auxiliary  operations  have  to  be  implemented. 

Another  major  problem  with  algebraic  specifications  involves  producing  a 
well-formea  specification,  i.e.  producing  a  complete  and  consistent  set  of 
axioms.  There  does  not  seem  to  be  any  straightforward  and  intuitive 
mathematical  procedure  for  checking  completeness  and  consistency. 
Inconsistencies  occur  when  axioms  result  in  two  objects  being  equivalent  when 
in  fact  tney  should  have  been  different.  A  complete  axiom  set  is  one  to  which 
an  independent  axiom  cannot  be  added.  A  more  thorough  discussion  of 
completeness  and  consistency  can  be  found  in  [GUTTJ80]. 

Operations  in  algebraic  specifications  are  all  functions.  They  do  not 
permit  side  effects  and  they  can  return  only  a  single  type  of  value.  In 
addition,  there  are  problems  with  partial  operations  and  error  equations 
([MAJSM79]).  The  problem  with  errors  occurs  because  an  error  is  not  of  the 


value  type  produced  by  an  operation  yet  it  may  be  the  value  produced  by  an 
operation.  This  can  lead  to  contradictions.  Goguen  ( [GOGUJ78J )  and  Guttug 
([GUTTJ77])  have  suggested  solutions  to  these  problems. 

Verifying  implementation  correctness  using  a  constructive  specification 
method  is  conceptually  easier  than  verifying  implementation  correctness  using 
algebraic  specifications.  Flon  ([FLQNL79] )  oescriDes  why  this  is  the  case. 
Algebraic  methods  deal  with  values  rather  than  objects.  Values  are  immutable; 
that  is,  an  operation  can  change  one  value  into  another  but  it  cannot  change 
the  state  of  a  particular  value.  This  means  that  operations  cannot  have  side 
effects  althougn  in  a  typical  procedural  implementation  operations  have  side 
effects.  For  instance,  in  an  implementation  of  pop  and  push,  these  stack 
operations  will  not  result  in  new  stacks  but  rather  will  alter  existing 
stacks.  Constructive  specification  methods  do  not  suffer  from  this  problem 
since  operations  specified  constructively  deal  with  changing  the  state  of 
objects. 

A  proof  of  implementation  correctness  must  be  done  for  each  operation  in 
a  constructive  specification  whereas  for  algebraic  specifications  we  must  show 
that  an  implementation  satisfies  each  axiom.  For  some  data  types,  the  number 
of  axioms  may  be  much  larger  that  the  number  of  operations.  From  our 
experience,  there  is  nothing  to  suggest  showing  that  an  axiom  is  satisfied  by 
an  implementation  is  any  easier  than  showing  that  an  implementation  of  an 
operation  is  correct  with  respect  to  a  homorphism.  This  suggests  that  the 
effort  required  to  prove  implementation  correctness  may  be  substantially 
larger  for  the  algebraic  approach  than  for  the  constructive  approach.  If  one 
of  the  operations  is  changed  then  all  of  the  axioms  referring  to  the 
corresponding  operation  will  have  to  be  reverified. 

In  general,  we  have  found  that  designing  abstractions  using  constructive 
methods  is  much  easier  than  the  algebraic  specification  method.  Minor  changes 
in  the  behavior  of  an  operation  are  easier  to  describe  for  constructive 
specifications.  A  modification  in  the  definition  of  one  constructively 


defined  operation  does  not  normally  affect  the  other  operations.  In  an 
algebraic  specification  the  meanings  of  the  operations  are  defined  in  terms  of 
the  relations  between  them,  so  that  a  change  in  an  operation  or  change  in  an 
axiom  can  affect  other  operations  ano  axioms.  It  is  difficult  to  produce  a 
well-formed  algebraic  specif ication  for  a  new  data  abstraction  especially  if 
the  exact  behavior  required  is  not  yet  completely  oesigned. 

A  major  complaint  against  constructive  specification  methods  is  that 
they  are  not  minimal,  i.e.  tnay  introduce  unnecessary  detail.  Proponents  of 
the  constructive  methods  argue  that  only  those  properties  that  are  necessary 
and  relevant  to  specifying  semantics  are  specified.  Auxiliary  operations 
required  by  the  algebraic  method  to  specify  some  data  abstractions  such  as  the 
dataabase  view  in  Figure  10  can  be  considered  to  be  unnecessary  detail. 

Another  complaint  against  constructive  specifications  is  that  they 
suggest  implementations  and/or  constrain  the  concrete  objects.  Berzins 
([BERZV79])  states  that  the  issues  of  time  and  space  efficiency  often 
requires  that  the  representation  used  in  an  implementation  differ 
significantly  from  the  model  used  in  the  specification  of  semantics.  One 
problem  inherent  in  a  constructive  specification  method  is  that  specifying  the 
semantics  of  complex  operations  may  be  quite  lengthy.  Constructive 
specifications  sometimes  lack  the  succinctness  found  in  algebraic 
specifications. 

In  general,  we  nave  found  constructive  specifications  easier  for  the 
user  of  a  type  to  interpret.  They  permit  an  implementation  to  be  more  easily 
developed. 

From  our  discussion  above,  it  appears  that  constructive  and  algebraic 
approaches  are  ideally  suited  for  some  applications  ana  poorly  suited  for 
others.  Unfortunately,  little  attention  has  been  devoted  to  the  problems  that 
occur  when  one  tries  to  integrate  the  kind  of  examples  occurring  in  the 
literature  into  real  software  written  in  real  programming  languages.  The 
examples  used  in  published  reports  have  been  well  known  mathematical  objects. 


These  objects  are  familiar  to  most,  thus  it  is  difficult  to  demonstrate  the 


value  or  specifying  trie  semantics  of  operations,  espe^uiU  t  .n  umiiumiiai  m1 
purposes  or  in  designing  data  abstractions.  Ine  database  view  example  in  this 
paper  and  in  [CLAYBBla],  [CLAYBBlbj  is  an  attempt  to  illustrate  the  important*- 
of  specifications  in  a  practical  situation.  Wnat  has  been  missing  in  the 
literature  are  examples  that  provide  user  oriented  operations  on 
non-mathemat ical  objects. 
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